Verified Boot

From Kicksecure
Jump to navigation Jump to search

Boot chain and integrity guarantees. What is Verified Boot, Secure Boot, Trusted Boot, dm-verity? Advantages, restrictions for user freedom, and more.

What is Verified Boot?[edit]

Verified boot is a security feature.

  • Purpose: Verified boot ensures that a system boots using only authorized and untampered software. Each stage of the boot process verifies the integrity and authenticity of the next stage before it is executed. This protects against attacks that modify the bootloader, kernel, or other critical parts of the system.
  • Process: During boot, the system checks cryptographic signatures on firmware and system components like the bootloader, kernel, and drivers. If the signatures don't match or have been tampered with, the boot process can be halted, or recovery measures can be triggered.

In theory, if used right, it improves the security of the user without restricting user freedom. In practice however, for a large part, verified boot is used to enforce user-freedom restrictions.

Let's start with the advantages, and a bit of technical background of verified boot.

Verified Boot strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption. It establishes a full chain of trust, starting from a hardware-protected root of trust to the bootloader, to the boot partition and other verified partitions including system, vendor, and optionally oem partitions. During device boot up, each stage verifies the integrity and authenticity of the next stage before handing over execution.

[...] Rollback protection helps to prevent a possible exploit from becoming persistent by ensuring devices only update to newer versions of Android.

In addition to verifying the OS, Verified Boot also allows Android devices to communicate their state of integrity to the user.Android Verified Bootarchive.org

Articles:

User Freedom[edit]

Freedom Software can be compatible with verified boot. No user freedom restrictions required. While verified boot is often used to restrict user freedom, to prevent the user from modifications and installing another operating system, verified boot is not inherently bad.

It depends on the details, if if the keys used to enforce verified boot are controlled by the vendor or by the user as well as on how the operating system implements verified boot. User-controlled keys are possible.

Nexus and Pixel lines support Verified Boot with user-controlled keysMike Perry, The Tor Project Blogarchive.org

Verified Boot Comparison of Third-Party Controlled versus User-Controlled[edit]

Category Vendor-Controlled Verified Boot User-Controlled Verified Boot
Improves security Yes Yes
Does not restrict user freedom No Yes
Does not hinder the user auditing their system for compromises. No Yes
Synonym 1 Tyrant Security Freedom Security
Synonym 2 Enterprise Security Cypherpunk Security
Empowers Corporates Individuals

Compromised Verified Boot Vendor Key[edit]

How does verified boot work?[edit]

It's based on digital software signatures. Only operating systems that come with a valid digital software signature that is signed with a public key that is trusted by the device are booted. Otherwise, the device will refuse to boot.

Lower stage (such as firmware) and hands over control to the next level (such as bootloader). However, every stage will verify the digital software signature of the next stage.

The stage are approximately (simplified):

hardware trust root → firmware → bootloader → kernel → kernel modules → initrd → init

Or specifically on some Linux desktop distributions:

hardware trust root → firmware → shim -> grub bootloader → Linux kernel → kernel modules → initrd → systemd init

Should at any stage the digital software verification fail, then the boot process will be aborted.

There is no technical requirement for each stage to be signed with the same key. Each stage can ship its own keys and/or key management system.

What are the advantages of verified boot?[edit]

Due to this integrity check, unauthorized malware will be gone after reboot (if the device is capable to revert to a clean backup image) or the device will refuse to boot.

Conceptually this improves security because the user runs only applications that have a valid digital signature. This obviously excludes third-party unauthorized malware since this would not be signed with a valid digital signature.

What are the limitations of verified boot?[edit]

Unauthorized malware? Is there such a thing as authorized malware, is this even a thing? Yes. For example the pre-installed Google Play Services on Google Android. See massive espionage data harvesting on Google Android. Verified boot is a security technology but conceptually cannot stop malware that is built-into the operating system by its producer. That does not take away from its useful potential as a security improvement for users.

Who uses verified boot?[edit]

At the time of writing, there was no Freedom Software Linux desktop distribution that implemented full verified boot which means a full chain of digital software verification starting form the hardware trust root up to all pre-installed applications that come with the Linux distribution. Only kernel module digital software verification is supported. The verified boot for initrd and beyond is not yet implemented. (Other Distributions implementing Verified Boot )

By comparison, for example Android and iOS supports full verified boot.

What are the dangers of verified boot?[edit]

The main risks are mistreatment of users, user software freedom restrictions, taking power away from users and handing it over to operating system and application developers.

As verified boot is currently implemented, for the vast supermajority of users the key is controlled by the operating system vendor. Users enrolling their own keys in the hardware key store or at any later stage of the boot process is often literally impossible [1], undocumented, not well supported, and even discouraged.

Many user-freedom restrictions are enforced using verified boot, locked bootloaders and non-root enforcement. This includes Android Anti-Features, prevention of replacing the stock operating system on mobile devices and many other mobile devices restrictions.

Verified Boot Compatibility with Rooted Phones[edit]

Yes, verified boot can be compatible with rooted devices.

Verified boot with root support and even with user-locked bootloader would be possible if support for that is built-in into the boot process (bootloader, recovery image). But how to modify the system partition without breaking verified boot? Modern root solutions such as for example Magisk support "systemless" root, via file system overlays. It's called "systemless" because Android has a partition /system that remains unmodified when using "systemless".

Verified boot would be compatible with root if an approach similar to such as for example Magisk is using built into the bootloader / recovery image prior signing it.

Furthermore, for compatibility with verified boot, user modifications to the system partition could be reset at device reboot boot time from a known signed good image. This is technically very doable because Android already does something similar with its A/B update mechanism. [2] Then how would the user make their system modifications persistent? Via file system overlays and/or automation scripts that run after the boot process. There could even be an boot menu option to boot with versus without user system modifications.

Related forum discussion: https://forums.whonix.org/t/overview-of-mobile-projects-that-focus-on-either-and-or-security-privacy-anonymity-source-available-freedom-software/4557/46archive.org

Rooted Security versus Non-Rooted Security[edit]

Quote [3]

And what the hell? Root with verified boot? That's like having the most secure castle while leaving the door open for anyone, you can't have both worlds.Anti user freedom viewpoint.

Root doesn't mean you give root permissions to any dumb app. I implied proper permission management and authorization, of course.

Then it's just like a secure castle where the user can go into all of the rooms, to some with a special key. You don't have to go into those rooms, but you have the option to at any time. And, depending on the implementation, you may change the special room, but if you return after the next reboot, it will be reverted back.

Actually, the castle analogy goes further: Unfortunately, many seem to interpret "verified boot" and "most secure" as "protects the dumbest user from shooting themselves in the foot on purpose by locking them into that castle. That is exactly where the recent apple scandal is coming from: The user is subservient to the OS vendor, and the OS vendor can abuse the user as they please.

Security is very important. Why? In order to not be exploited by strangers (criminals, spys...) against my interests. If security enables exploitation against my interests (by whomever, be it the OS vendor, the movie industry, or the government), it is not the security I want. This one OS is different than all the other evil ones? That's what Apple said before...Pro user freedom viewpoint.

If you're rooted your security is way lower. Simple as that. Rooting can be used against you, it can lead to exploitation, and likely has been. Note: you can have secure boot without root and using your own Android build, such as CalyxOS. Not rooting doesn't imply using the stock firmware, never has been.Anti user freedom viewpoint.

I honestly don't understand why it should be "Simple as that"? If you have the phone rooted, as long as you don't grant root to any application, why should it be less secure than if you hadn't rooted it? (assumed everything else the same, specifically the rom supporting verified boot with root) Then, by granting root permissions to apps, of course the attack surface gets larger, but this is a thing you control yourself. Your note was always understood. Of course not rooting doesn't imply using the stock firmware. It however implies that you are submitting to a different master. Who may be different, and maybe a bit more lenient than Google/Samsung/whoever, but that other master will still enforce any dumb app's will against you.Pro user freedom viewpoint.

Ideological Considerations[edit]

Before discussion the technical implementation details and security it might make sense to lay out one's position on who should have more power. Device owners or vendors.

  • Should the operating system obey the user? Yes | No
  • Should the user should have ultimate control? Yes | No
  • Should the operating system make guarantees to app developers in case these guarantees are to the disadvantage of the user? Yes | No
  • Does one oppose the war on War on General Purpose Computing? Yes | No
  • Does one support the right to general computing? Yes | No

It is primarily a project goal and policy decision.

Technical excuses are mood. If there's a commitment pro freedom and against anti-features, then there's a way. Security needs to take the backseat if it curtails user freedom. A prison cell is more secure from car accidents but yet we don't want to live in a golden cage. If you want, you will find a way, if you don't want to, you will find reasons.

For example, in case of GrapheneOS non-root enforcement is a project goal and policy decision.

It doesn't sound like you want GrapheneOS since you don't care about the core security goals. I recommend using something else.GrapheneOS lead developerarchive.org [4]

GrapheneOS is not aimed at power users or hobbyists aiming to tinker with their devices more than they can via the stock OS or AOSP.

(resign-android-image is a script that attempts to provide root access for GrapheneOS.)

Verified Boot Security[edit]

Potential misconception:

Verified boot makes sure the code that is booted is safe, and then from that point on its job is done.

Quote https://source.android.com/docs/security/features/verifiedboot/verified-bootarchive.org

verification is a continuous process happening as data is loaded into memory

This means if malware manages to modify the file move program /usr/bin/mv despite immutability, then dm-verity would notice this the next time the user or system is attempting to execute that command.

Verified Boot Discussion[edit]

Does Verified Boot Require an Immutable Image?[edit]

Does verified boot necessarily require an immutable (read-only) image? Does verified boot make any sense with read-write?

Can verified boot be useful for a general-purpose operating system?

Modified Files[edit]

Modified files:

  • The main problem when attempting to combine verified boot with full read-write access is that the user (or malware) can modify any file in /etc or /usr.
  • Let's consider running a tool that can show modified files in /etc and /usr.
    • debsums -ce
  • Sample output might include:
    • /etc/xdg/Thunar/uca.xml
  • This means that configuration file /etc/xdg/Thunar/uca.xml has been modified for some reason. Users have many legitimate reasons to modify files. However, malware might also modify files. Malware might drop a startup unit in /etc/systemd/system/, but so might a desktop user or server system administrator.

New or Deleted Files[edit]

New or deleted files: On top of that, it would need to be ensured that there aren't any new files or deleted files that could be planted by malware for the purpose of a persistent backdoor. For example, a drop-in into /etc/profile.d or a systemd unit file or drop-in. These can serve many legitimate purposes but can also be abused by malware.

Read-Write + Verified Boot Challenges[edit]

Read-write + verified boot - the anything changeable issue: The main problem with verified boot without immutability is that both the user and an adversary can change pretty much anything on the hard drive.

Implementing Verified Boot - Minimal System Partition[edit]

One concept to implement verified boot is an immutable, minimal system partition. That, however, is mostly suitable for specialized appliances (such as routers). The disadvantage is a lot of lost user functionality and freedom. It would be a hard and dictatorial decision about what goes into the system partition, which couldn't be modified by the user without building from source code. A long running process that can maybe be speed up and simplified.

Compromises Between Mutability, Functionality and Security[edit]

It would kind of force some specific technology on the user (for example, going all in on Flatpak for application installation).

Freedom to modify in-place and security are at odds with each other. Anything that is secured by verified boot becomes immutable.

Non-Persistence in Verified Boot[edit]

Is it possible to at least get the compromise of non-persistence from verified boot? Yes, but then one ends up with things like "I rebooted and now all the software I installed is gone." Verified boot with reset after reboot would be similar to live mode. So even if full apt-get install access was permitted, that would be gone after reboot.

Persistence of User-Installed Packages[edit]

Can user-installed packages using apt-get install persist + verified boot? debsums alike functionality? [5] One would have to trust everything in the apt repository to make that safe, which might be an acceptable assumption, and somehow prevent the user from adding additional repositories or installing deb packages that they built themselves.

Mutability in Verified Boot Systems[edit]

Some verified boot in combination with mutable (read-write) issue:

  • Just how mutable? Should systemd units be mutable or immutable? If immutable, many packages won't be installable. If mutable, setting up a persistent backdoor becomes easy. If "live-immutable," software will break after a reboot.
  • Verified boot with mutability will be too easy to bypass. If someone leaves, for instance, /usr/local/bin mutable because "of course it should be mutable, that's where user-installed software goes," malware might plant a malicious executable there that will now be persistent and override calls to an executable in an immutable /usr/bin.
  • System updates? Verify and copy files to the "fake-immutable" base filesystem after a successful update? What if a non-persistent compromise manages to compromise the updater so it copies malicious files to the base partition?

Challenges with Immutable Filesystems[edit]

With a real immutable filesystem, updates become hard. It would require system image updates rather than apt packages for the base system, but somehow maintain compatibility with apt packages too.

For real immutability, we would need to invent A/B updates for Debian. Vanilla OS is doing A/B updates with Debian Sid.

Verified Boot for Specialized Operating Systems[edit]

So verified boot can only always be specialized operating systems, not general-purpose operating systems? As in "This is a nice verified boot image, start the browser, reboot, any potential malware compromise will self-heal."

Minimal Immutable Base Images in combination with chroot[edit]

Suppose there is this minimal immutable base image... And then a chroot where the user can do anything? We might not get too much from that. It requires an entire ecosystem. And the Debian ecosystem doesn't really have verified boot on the radar.

Approaches from Other Distributions[edit]

The approach Fedora Silverblue takes, only they also allow Flatpak and root fs modification via rpm-ostree. TODO: security impact?

Factory Reset and Verified Boot[edit]

With a read-write (rw) image and verified boot, at best maybe what one could get is a simple factory reset in the boot menu. The user could choose factory reset, which resets all changes in the root image. Nice, but not that great of a feature.

Challenges of Using dm-verity[edit]

One cannot do dm-verity on a "normal" filesystem. Only on images, block devices. Any changes and it breaks. Quote dm-verity man page:

Device-Mapper’s “verity” target provides transparent integrity checking of block devices using a cryptographic digest provided by the kernel crypto API. This target is read-only.

One ends up with a read-only filesystem.

Allowing Mutability with dm-verity[edit]

To allow this to be mutable, one needs to have some way of applying changes to it, which requires some way of automatically signing those changes, which might exposes the key to malware should it infect the system.

Quote systemd-sysext:

Files and directories contained in the extension images outside of the /usr/ and /opt/ hierarchies are not merged, and hence have no effect when included in a system extension image. In particular, files in the /etc/ and /var/ included in a system extension image will not appear in the respective hierarchies after activation.

Or systemd-confext for /etc.

Kicksecure ISO and Verified Boot[edit]

How useful would it be to have verified boot for Kicksecure ISO? Since it's read-only anyhow.

ISO Considerations[edit]

It's hard to modify an ISO read/write. There is no public software available to really mount an ISO read/write. But it's possible in theory. The ISO should be considered read-write for attackers but read-only for the public. There is the Open Source growisofs tool. Also, other attacks are conceivable such as repacking the ISOarchive.org, which is documented in the Debian wiki and much easier than ISO.

Verified Boot for USB Installations[edit]

Suppose someone writes the ISO to USB. Then the live session is compromised. By clever ISO read/write editing, the ISO compromise is made persistent. Would verified boot be able to come to the rescue here? It might.

Challenges with Key Management with Secure Boot[edit]

The computer needs to have the proper Secure Boot keys somewhere to verify the ISO image and detect if it is compromised. Due to how shim is implemented on Freedom Software Linux distributions, in practical terms, one might need to rely on Microsoft's keys. A lot of this is elaborated on the Dev/Secure Boot wiki page. This means the attacker must not be able to access a leaked Microsoft key. This is not only a theoretic consideration. Microsoft's signing key has been leaked in the past, see Compromised Verified Boot Vendor Key.

Furthermore, any shim signed my Microsoft (such as Debian's shim) would still be bootable along with other maliciously modified operating system parts (part of Debian).

This approach doesn’t benefit Freedom Software Linux desktop distributions much since they must use their own key to verify the filesystem image. That image is created by the distribution, so their shim must be signed with Microsoft's key.

One major issue is, that an EFI executable, such as shim, cannot have two signatures. This is an EFI design limitation.

Options for key management:

  • A) Distribution signing key as hardware root of trust: The distribution signs shim, and the user uses the distribution's key in the firmware (BIOS / EFI); or
  • B) User managed keys: the user manages their own keys (which is even less realistic); or
  • C) Micorsoft key: the distribution relies on the Microsoft key (e.g., the default Debian shim).

Microsoft Signing Process[edit]

There isn’t a single universal shim. Even large distributions like Pop!_OS lack Secure Boot; only major distributions (e.g., Ubuntu, Debian, Fedora, openSUSE) have implemented it.

Microsoft would likely be willing to sign a new Linux distribution shim. The Linux distribution "just" need to fork shim and then go through the shim review process. Many distributions have managed to get their shims signed, though the requirements for doing so are strict (e.g., key storage must be physically secure and require biometric authentication).

This is nice to have for Secure Boot compatibility, which is a lesser goal of at least having a bootable Linux distribution without the user having to disable Secure Boot in their BIOS. Kicksecure is Secure Boot compatible, thanks to Debian's shim, but this relies on appearing as Debian.

It's however not much of a security feature, since attackers with access to (leaked) Microsoft keys can bypass it. The root of trust ultimately resides with Microsoft.

If Kicksecure would provide ISO with our our own key for signed verified boot images, we would lose compatibility to boot on standard hardware with Secure Boot and Microsoft's default key. The "only one signature allowed on an EFI binary" restriction is preventing that. Kicksecure might need to maintain two different ISO's.

  • A) Kicksecure hardware ISO: One ISO signed for hardware sold by Kicksecure that only comes by default only with Kicksecure's key.
  • B) General Secure Boot hardware ISO: For "normal", non-Kicksecure hardware.

Alternative Approaches[edit]

Custom Hardware with Specific Keys[edit]

One solution could be selling certified hardware with the project-specific key while removing the Microsoft key. But that is likely unrealistic. Another approach could involve a single ISO with two bootloaders, or separate ISOs for Microsoft-key-compatible and project-specific-key-compatible boot options. However, this adds complexity.

Dual Shim Fallback Mechanisms[edit]

A potential compromise could be a fallback mechanism with two shims: one based on the Microsoft key and another on the project-specific key. The system could transparently switch to the secondary shim if the primary fails. But implementing this is a significant challenge.

Lessons from Preinstalled Systems[edit]

When machines certified for other distributions (e.g., Ubuntu) are preinstalled, they include an Ubuntu-specific key from Canonical alongside the Microsoft key. However, relying on Secure Boot for verified boot while keeping compatibility with the Microsoft key poses challenges.

Measured Boot vs Secure Boot[edit]

It’s possible to design a process where the Microsoft shim loads the kernel, the kernel then determines compatibility with the project-specific key, and the system reboots into a secondary bootloader signed by the project. But this approach requires additional firmware capabilities. TODO: effectively can be compromised with Microsoft leaked key?

Another consideration is whether removing the Microsoft key is beneficial. While it would lock systems to the Linux distribution's key for Secure Boot, this might restrict compatibility further than Microsoft’s own Secure Boot implementation. A firmware option to enable or disable Microsoft or project-specific keys could address this.

Measured Boot, an alternative to Secure Boot, avoids the Microsoft key issue. While Secure Boot prevents unauthorized code from running, Measured Boot provides tamper evidence, which may be sufficient for many use cases. However, implementing this requires firmware support and careful design.

Potential Verified Boot Workflow[edit]

A feasible workflow might involve Secure Boot launching shim (signed by Microsoft), shim launching a measured boot utility (e.g., stboot), and stboot verifying the kernel and root filesystem. This would provide a chain of trust extending from firmware to userland. However, integrating stboot into this process is complex.

Key Management and User Complexity[edit]

Ultimately, projects relying on their own key for signing or implementing Secure Boot independently of Microsoft face significant technical and logistical hurdles. While it’s possible to use external storage for managing measurements, this increases user complexity and introduces new risks.

Kicksecure Verified Boot Development Ideas[edit]

Verified VM Boot Sequence without Secure Boot[edit]

Talking about VMs only in this concept.

We could boot from a virtual, read-only (write-protected) boot medium such as another virtual HDD or ISO. Such a boot medium, which only contains a bootloader (shim or grub?), has the sole task of verifying the bootloader on the main hard drive that contains the bootloader, kernel, and Debian. That boot medium (such as ISO) could be shipped on Kicksecure Host through a deb package: /usr/share/verified-boot/check.iso.

Presuppositions

  • The virtual BIOS cannot be flashed/compromised.
  • Host is not compromised.

Boot Sequence

VM powered on → virtual BIOS loads boot DVD ISO (or alternatively another hard drive) (contains a bootloader only) → this initial bootloader signature is not verified but secure since booting from a read-only medium → verify bootloader on main hard drive → bootloader of main hard drive does signature verification of kernel → continue boot.

Requirements

  • grub-pc (not grub-efi) with signature verification. [6]

By not booting from that initial boot medium (for testing or if it was broken), users could perform regular boots without verification of the bootloader on the main drive. From the perspective of the main drive, nothing would change, except we'd enable grub signature verification of the kernel on the main drive.

Simplification

The boot medium should not load the actual kernel for simplicity of implementation. Since it is read-only, it cannot be easily updated. Kernel packages change, and during kernel upgrades, /boot and grub.cfg on the main disk change. If /boot were write-protected, that would fail. Therefore, the initial boot medium is only a simplified alternative to EFI Secure Boot. By making the initial boot medium as simple as possible, i.e., only chainloading the next bootloader, it does not need frequent updates and does not need to be updated when kernel versions change.

If we could make grub-pc (not grub-efi) use check_signatures=enforce, then perhaps we don't need to port to EFI and/or Secure Boot soon or perhaps never.

enable Linux kernel gpg verification in grub and/or enable Secure Boot by defaultarchive.org

Disadvantages

Hash Check all Files at Boot[edit]

Higher security level than Secure Boot.

This concept applies only to virtual machines (VMs).

We could boot from a virtual, read-only (write-protected) boot medium, such as another virtual HDD or ISO. Such a boot medium could run a minimal Linux distribution, which then compares against checksums from the Debian repository on the main boot drive:

  • The MBR (Master Boot Record)
  • The VBR (Volume Boot Record)
  • [A] The bootloader
  • [B] The partition table
  • [C] The kernel
  • [D] The initrd
  • [E] All files shipped by all packages

There are tools that can help with checking all files on the hard drive, such as debsums. However, debsums, while more popular, is unsuitable. [7]

A tool such as debcheckrootarchive.org might be more suitable for this task.

During the development of Verifiable Builds, experience was gained in verifying the MBR, VBR, bootloader, partition table, kernel, and initrd. Source code was created to analyze such files. [8]

Extraneous files would be reported, with options to delete them, move them to quarantine, and/or view them.

The initrd, by default in Debian, is auto-generated on the local system. Hence, there is nothing to compare it with from the Debian repository. However, after verifying everything (all files from all packages), it would be secure to chroot into the verified system and re-generate the initrd, then compare both versions. This step might not be required if the initrd can be extracted and compared against files on the root disk.

That boot medium (such as ISO) could be shipped on the Kicksecure Host through a deb package located at /usr/share/verified-boot/check.iso.

A disadvantage of this concept is that it might be slower than dm-verity. On the other hand, an advantage of this concept is that it does not require an OEM image. Additionally, it might be more secure since it does not verify against an OEM image but instead verifies the individual files. Another advantage is that users are free to install any package and are not limited by a read-only root image. Users do not have to wait for the vendor to update the OEM image.

dm-verity - system versus user partition[edit]

Once the boot chain is verified, the kernel should verify the rest of the OS with a mechanism similar to dm-verity. Verified boot that covers only the boot chain is mostly useless, with some exceptions. [9]

We can implement two separate partitions: one for the base system and another for user-installed applications. The base system partition can be mounted as read-only and verified with dm-verity. The apps partition can be mounted as /apps, and chroot into it. The apps partition, however, will not be verified.

For example:

mount /path/to/unverified_image /apps for dir in bin sbin usr lib lib64 var etc do mkdir "/apps/${dir}" mount -o bind "/${dir}" "/apps/${dir}" done mkdir /apps/{proc,sys,dev} mount proc /apps/proc -t proc mount sysfs /apps/sys -t sysfs mount devtmpfs /apps/dev -t devtmpfs mount devpts /apps/dev/pts -t devpts apt install -o Dir=/apps $program chroot /apps $program

Verified Boot for User but not for Admin[edit]

This idea integrates well with Role-Based Boot Modes (user versus admin) for Enhanced Security and noexec.

  • When booting into user user, enable verified boot by default.
    • User user will not be able to modify /etc, /usr.
    • Therefore the user will not have the ability to successfully execute sudo apt install package-name.
  • When booting into user admin, disable verified boot by default.
    • After booting into admin mode, admin can run sudo apt install package-name etc.
    • Based on dpkg trigger or shutdown, a new dm-verity has tree will be created, that will be used next time booting into user mode.

Status[edit]

Other Distributions implementing Verified Boot[edit]

Immutable Linux Distributions[edit]

Vanilla OS, an immutable desktop Linux distribution designed for developers and advanced users,https://lwn.net/Articles/989629/archive.org

Forum Discussion[edit]

See Also[edit]

Footnotes[edit]

  1. ↑ Many Android devices come with locked bootloaders. Many Android phones could not have been modded by the modding community because no way to break the verified boot chain and gain full read/write access to their own devices could be found.
  2. ↑ https://source.android.com/docs/core/ota/abarchive.org
  3. ↑ https://news.ycombinator.com/item?id=28096914archive.org
  4. ↑ https://archive.ph/94YVQarchive.org
  5. ↑ debsums -ce debsums is not secure yet. It uses insecure checksums. But that might be fixable with an alternative implementation.
  6. ↑
  7. ↑ Quote https://www.elstel.org/debcheckroot/archive.org

    Usage of debsums instead of Debian-checkroot is strongly discouraged because debsums uses locally stored md5sums which can be modified by an attacker along with the files themselves. It has been meant for integrity checking, not for security issues! Debsums furthermore does not provide an output as clean and neatly structured as checkroot and does not spot files additionally added to your system by someone else.

  8. ↑ https://github.com/Kicksecure/derivative-maker/blob/master/build-steps.d/5100_create-reportarchive.org
  9. ↑ For example, Kicksecure loads apparmor.d from the initramfs, which it will cover.
Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Verified_Boot&oldid=88421"